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SERVICE/DEVICE INDICATION WITH GRAPHICAL INTERFACE 

This international application claims priority to U.S. Serial Number 10/101,688, filed 
5 March 2 1 , 2002, entitled, "SERVICE/DEVICE INDICATION WITH GRAPHICAL 
INTERFACE", and which is incorporated entirely herein by reference. 

FIELD OF THE INVENTION: 

The invention disclosed broadly relates to ubiquitous computing and more 
10 particularly relates to improvements in short range RF technology. 

BACKGROUND OF THE INVENTION: 

Bluetooth is a short-range radio network, originally intended as a cable replacement. 
It can be used to create ad hoc networks of up to eight devices operating together. The 

15 Bluetooth Special Interest Group, Specification Of The Bluetooth System . Volumes 1 and 2, 
Core and Profiles: Version 1.1, February 22, 2001, describes the principles of Bluetooth 
device operation and communication protocols. The devices operate in the 2.4 GHz radio 
band reserved for general use by Industrial, Scientific, and Medical (ISM) applications. 
Bluetooth devices are designed to find other Bluetooth devices within their ten-meter radio 

20 communications range and to discover what services they offer. 

A connection between two Bluetooth devices is initiated by an inquiring device 
sending out an inquiry message searching for other devices in its vicinity. Any other 
Bluetooth device that is listening by means of conducting an inquiry scan, will recognize the 
inquiry message and respond. The inquiry response is a frequency hop synchronization 

25 (FHS) packet containing all of the information required by the inquiring device to address the 
responding device. This information includes clock value of the sender (i.e., the responding 
device), the sender's correct device access code, and the class-of-device (CoD) field. The 
FHS packet contains more information than is mentioned here. The access code includes the 
lower address part (LAP) and the upper address part (UAP) of the sender's Bluetooth Device 

1 
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Address (BD_ADDR), a unique, 48-bit IEEE address that is electronically engraved into each 
Bluetooth device. 

The class-of-device (CoD) field of the FHS packet indicates which device class the 
sender belongs to, such as printer access point, network access point, PDA, cellular 
5 telephone, and the like. The class-of-device (CoD) field is a 24 bit field divided into three 
subfields and a two-bit format field. The high order eleven bit subfield is reserved for 
indicating general service classes such as information, telephony, audio, object transfer, 
capturing, rendering, networking, and positioning. The middle five bit subfield comprises the 
major device class, which can indicate up to 32 different device types. The low order six bit 

10 subfield consists is the minor device class, which can indicate up to 64 different variations of 
each device type. The lowest order two bits are the format field for identifying the format 
type of the CoD field. 

The inquiring device (after it sends a paging packet) will become the master and the 
responding device will become the slave in the eventual piconet, if a connection is 

15 established. To establish a connection, the inquiring device must enter the page state. The 
paging device uses the information provided in the inquiry response packet, to prepare and 
send a paging message to the responding device. The paging device uses the estimated clock 
CLKE and access code of the responding device (i.e., the eventual slave device) to 
temporarily synchronize with it. Since the paging device intends to be the master, it includes 

20 an assignment of an active member address (AM_ADDR) in the paging message. The paging 
message sent by the paging device is also a frequency hop synchronization (FHS) packet 
containing all of the information required by the responding device to directly reply to the 
paging device. This information includes clock value of the sender (i.e., the paging device) 
and the paging device's correct device access code. The responding device must be in the 

25 page scan state to allow the paging device to connect with it. Once in the page scan state, the 
responding device will receive the paging packet that provides the clock timing and access 
code of the paging device. The responding device responds with a page acknowledgment 
packet. This enables the two devices to form a connection and both devices transition into 
the connection state. The paging device that has initiated the connection assumes the role of 
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a master device and the responding device assumes the role of a slave device in a new ad hoc 
network piconet, using the CLK clock timing and access code of the master device. 

Each piconet has one master device and up to seven active slave devices. All 
communication is directed between the master device and each respective slave device. The 
master initiates an exchange of data and the slave responds to the master. When two slave 
devices are to communicate with each other, they must do so through the master device. The 
master device maintains the piconet's network clock and controls when each slave device can 
communicate with the master device. Members of the ad hoc network piconet join and leave 
as they move into and out of the range of the master device. Piconets support distributed 
activities, such as multi-user gateways to the Internet or to a content server, wherein one 
device serves as the access point and is connected to an infrastructure network or content 
server. A user's device that joins a multi-user gateway piconet, does so to enable its user to 
access the infrastructure network or content server. 

To form ad hoc connections, a Bluetooth device has to have the ability to rapidly 
discover target Bluetooth devices to which the user wishes to connect. In many cases the 
target device is known, e.g. a headset, and thus the procedure for connection establishment is 
straightforward. However, in certain cases it is not possible to have information about the 
target device. Additional problems are created by a crowded environment where many 
Bluetooth devices are present, which respond to the user device's inquiries. 

What is needed a way to rapidly give the user notice of those Bluetooth devices 
within communication range, and yet not inundate the user with information about those 
Bluetooth devices that he/she wishes to ignore. 

SUMMARY OF THE INVENTION 

The invention disclosed gives the user notice of those Bluetooth devices within 
communication range, and yet it selectively blocks any notice about Bluetooth devices that 
the user wishes to ignore. In accordance with the invention, Bluetooth server devices can 
indicate to the user's Bluetooth client device the service that the server device has available 
by sending service/device icon information to Bluetooth client device. This information can 
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be a value in the class-of -device (CoD) field of a frequency hop synchronization (FHS) 
packet that it sends during the process of exchanging inquiry and paging packets with the 
Bluetooth client device. If the server device has begun by transmitting an inquiry packet, 
then the CoD value will be sent in its paging packet. If the server device is responding to an 
5 inquiry, then its CoD value will be in its inquiry response packet. 

The service/device icon is a small, graphic bitmap that is displayed on the screen of 
the client device, having an appearance that serves to describe the service that the server 
device has to offer. Alternately, the icon can also serve to identify characteristics of the user 
of the server device, such as business-related or personal characteristics. In either case, the 

10 icon bitmap must reside in the client device in order to be displayed on its screen. For 

conventional services, such as an access point for an Internet gateway or an access point for a 
printer, standard icon bitmaps can be stored in an icon cache in all Bluetooth client devices. 
Optionally, new icon bitmaps and their corresponding CoD values can be downloaded from 
an Internet service provider, such as Nokia Club, to be stored in the icon cache of the client 

15 device in association with their CoD values. This can be, for example, a new graphical 
design of an icon for an existing, assigned CoD value, such as that for a printer. The 
service/device icon is typically a 16 by 16 pel bitmap. A black and white icon can be stored 
in a 32-byte memory partition of the receiver's icon cache. An eight bit per pel color icon can 
be stored in a 256-byte memory partition of the receiver's icon cache. Audible tones can be 

20 played when the icon is initially displayed. The tone string can be downloaded from the 

Internet service provider at the same time as is the icon bitmap and stored in the icon cache of 
the client device in association with the CoD value. 

When the icon is initially displayed on the screen of the client device, a partition is 
opened in a detected icon buffer to store the status of the icon. A time stamp value is 

25 recorded at the start of the display, in association with the received CoD value. Periodically, 
the time stamp value is compared with the time of day clock of the client device. When the 
time stamp is older than a threshold value called the lease-time (30 seconds, for example), the 
icon is removed from the screen and its partition is closed in the detected icon buffer. During 
the period that the icon remains actively displayed on the screen, if additional FHS packets 
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are received from the same server device containing the same CoD value, the time stamp 
value is updated to the current time of day value. This enables retaining the display of an 
icon for a server device that remains in the vicinity of the client device. As soon as the client 
device moves out of communications range of the server device and no more FHS packets are 
5 received, then after the expiration of the lease-time, the icon is removed from the screen. 

If the client device has initiated a connection with the server device to carry out SDP 
searching or other operations, the client device assumes a temporary master role in its new 
piconet. Most server devices are programmed to request a master/slave role switch if the 
client device has initiated the connection. Once the client changes to a slave role, it can only 

10 remain in its piconet, either as an active slave or a parked slave. (It is possible for the slave 
to switch between several piconets, when timing information is known.) Thus, the client 
device is programmed to terminate such connections after completing any necessary SDP 
searching or other operations. In order to continue displaying icons of server devices within 
communications range, the client device continues to operate in the inquiry and page 

1 5 scanning modes, detecting the FHS paging packets and FHS inquiry response packets from 
server devices in its vicinity. When the FHS packets from a given server device are no longer 
received, then the lease-time interval is started in preparation to remove the corresponding 
icon from the display. 

The detected icon buffer also stores the Bluetooth device address BD_ADDR of the 

20 server device, in association with the received CoD value. The ith icon in the detected icon 
buffer has a device address BD_ADDRi and a CoD value CoDi. The detected icon buffer 
also stores coordinates, such as the (x,y) coordinates, of the displayed position of the icon 
with respect to the origin of coordinates on the screen, in association with the received CoD 
value. The ith icon on the screen has a position (xi,yi) associated in the detected icon buffer 

25 with the its CoD value CoDi. Other origins for coordinates can be used, such as the center of 
the screen. Also, other coordinate systems can be used, such as polar coordinates. A cursor is 
also displayed on the screen, whose position is represented by coordinates, such as the (X,Y) 
coordinates with respect to the origin of coordinates on the screen. A pointing device, such 
as a mouse or a track ball controls the displayed position (X,Y) of the cursor on the screen. 
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When the user presses the mouse button, the (X,Y) coordinates of the cursor are compared 
with the (x,y) coordinates of each icon in the detected icon buffer. If the cursor coordinates 
(X,Y) are within range of the ith icon coordinates (xi.yi), then the ith icon is selected. The 
client device can be programmed to access the device address BD_ADDRi to complete the 
5 connection with the corresponding server device and exchange further messages with it. The 
further messages can include the client device sending an SDP request to the server device to 
find out information about other files or services, followed by accessing a file from the server 
device. 

Where the server device has initiated the connection by sending inquiry and paging 

10 packets to the client device, the server device may use the Bluetooth object push profile 
(OPP) to push an unsolicited file, such as a business card, to the client device. The client 
device is programmed to store the unsolicited file in a unsolicited file buffer, associated with 
the CoD and the BD_ADDR of the sending server device. The detected icon buffer opens a 
partition for the server device and stores an indication that there is an associated file in the 

15 unsolicited file buffer. When the user presses the mouse button, the (X,Y) coordinates of the 
cursor are compared with the (x,y) coordinates of each icon in the detected icon buffer. If the 
cursor coordinates (X,Y) are within range of the ith icon coordinates (xi,yi), then the ith icon 
is selected. The client device can be programmed to check if there is an associated file in the 
unsolicited file buffer. If there is, that file is accessed and displayed on the screen. This 

20 feature enables the server device to send more informative messages to the client device, 
along with the CoD of the icon bitmap. 

The detected icon buffer also stores a server rank value, in association with the 
received CoD value. The first server device of a given CoD type to be entered into the 
detected icon buffer will be assigned the a server rank value of "1". Two different server 

25 devices having different device addresses BD_ADDR, can offer the same service and will 

transmit the same CoD value. The client device is programmed to identify this circumstance. 
The second server device of the same CoD type to be entered into the detected icon buffer 
will be assigned the a server rank value of "2", and so on. Instead of placing two identical 
icon bitmaps on the screen, the first displayed icon will have appended to it a numeral 
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indicating how many of that type of server device are in the vicinity. The displayed icon is 
referred to as a multi-icon. 

The detected icon buffer also stores a received signal strength indication (RSSI) for 
each respective server device listed in the detected icon buffer. Where there are two or more 
5 server devices in the detected icon buffer having a given CoD type, the client device is 
programmed to rank them by their RSSI values. The server rank values of those servers 
having the same type CoD value are reassigned, in accordance with the RSSI for each server 
device. The server device with the strongest RSSI will be reassigned a server rank value of 
"1", and weaker server devices will be assigned consecutively greater values. When the 

10 cursor coordinates (X,Y) are within range of the multi-icon's coordinates (xi.yi), then the 
multi-icon is selected. The client device can be programmed to access the device address 
BD_ADDRi of the server device with the strongest RSSI to complete the connection with 
the corresponding server device and exchange further messages with it. As individual server 
devices move out of communication range of the client device, the respective partition in the 

15 detected icon buffer is cleared, and the server rank values are reassigned, as needed. 

The RSSI value can be displayed beneath each icon shown on the screen, thereby 
allowing the user to select server devices having better link quality. Alternately, "color bars" 
can be presented to represent RSSI values , such as green = good RSSI, yellow = still 
acceptable, and red = data transmission is not possible. Any kind of indication of RSSI 

20 reading is possible (e.g. actual value, number of bars, color etc) 

The user can enter CoD values for types of server devices or services to be ignored, 
such as advertisement broadcasting server devices and certain types of vending machine 
server devices. These prohibited CoD values are stored in a blocking filter buffer in the 
client device. When a CoD value is received in an FHS packet, it is compared with the 

25 prohibited CoD values and if there is a match, no entry is made in the detected icon buffer, 
thereby ignoring the prohibited server devices. 

There are up to eleven bits available in the CoD field for assignment as service 
descriptions, yielding up to 2048 different possible services that can be represented. Some 



7 



WO 03/081373 



PCT/1B03/00909 



subset, for example the six bits of the CoD minor device class sub-field, can be used to assign 
up to 64 service description values. 

When the icon serves to identify characteristics of the user of the server device, such 
as business-related or personal characteristics, the device can be optionally programmed to 
5 accept manual changes to the CoD field. The user of the sending device has the ability to 
select the icon to be sent. Optionally, the server device can be manually reset by its user to 
indicate in its class-of-device (CoD) field of its FHS packet, that particular types of 
service/device icon information are available, such as dating/match-making information. 
The client device can also be programmed to search for specified class-of-device 

10 (CoD) values received from a server device. The client device can match the CoD values 
received in FHS packets, with an entry in a search list in the client device. For example, the 
client device can be programmed by its user to search for that particular class-of-device 
(CoD) value among those CoDs received. When a match is found, the client device is 
programmed to display the icon bitmap and sound an alarm tone. 

15 In the current Bluetooth specification, an inquiry result is reported over the Host 

" Computer Interface (HCI) only after the inquiry period is over, which is 10.24 seconds. 
During that period, it may be possible that the client device will move out of the range of the 
server device. In another aspect of the invention, the receipt of FHS packets is a result event 
that is reported over the HCI as soon as each new FHS packet arrives. The HCI is 

20 programmed to write the received CoD value of the FHS packet in a memory register at the 
time that the packet arrives. The Host can then read the register and process the CoD value to 
display the corresponding icon, as described above. 

The client device can be programmed by its user to recognize selected class-of-device 
(CoD) values and either ignore them or display the corresponding icon bitmap. 

25 In an alternate embodiment of the invention, the service/device icon information can 

be sent after a connection has been made with the client device, as part of a Service 
Discovery Protocol (SDP) response packet. The client device can search for interesting 
services using the Service Discovery Protocol (SDP). When interesting services are found, 
their service records are accessed by the client device. Icons are included in the service 
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records as an IconURL parameter. Icons can be loaded using hypertext transfer protocol 
(http). If there is no icon included in the service record of an interesting service, a default 
icon for its type may be displayed, as identified by the CoD value of the sending device. 

The process of retrieving the icon bitmap in the Service Discovery Protocol (SDP) of 
5 the alternate embodiment, starts by examining the public browse root of the SDP service 
registry in the server device. It then follows the hierarchy out to service classes which are the 
branches of the tree, and from there to the leaf nodes, where individual services are described 
in service records. To get specific information about the icon bitmap, the client device and 
the server device exchange messages carried in SDP packets. There are two types of SDP 

10 packets, the SDP Service Search Attribute Request packet and the SDP Service Search 
Attribute Response packet. The SDP Request packet carries the SDP Service Search 
Attribute Request, which includes a service search pattern and an attribute ID list. The 
service search pattern is the description of the desired service records containing the icon 
bitmap information in the server device. The server device specifically searches its registry 

15 of for the attribute containing information about the icon bitmap. The server device responds 
with the service handle of the icon bitmap or a pointer to the icon bitmap. The service handle 
identifies the service record containing the icon bitmap. Optionally, the service record 
contains a pointer to the icon bitmap. When the client device receives the icon bitmap, it is 
displayed on the screen. Optionally, it can also be stored in the client's icon cache. 

20 

DESCRIPTION OF THE FIGURES 

Figure 1 A shows a wireless network diagram of the Bluetooth mobile client device 
and five server devices, with the mobile device being within Bluetooth communication range 
of a network access point, a first printer access point, and a vending machine access point, 
25 according to an embodiment of the present invention. 

Figure IB shows the same wireless network as Figure 1A, but with the mobile client 
device having moved out of the range of the network access point and into range with a 
second printer access point. 
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Figure 1C shows the same wireless network as Figures 1 A and IB, but with the 
mobile client device having further moved out of the range of both the network access point 
and the first printer access point, and into range with a second mobile device. 

Figure 2 shows the memory layout of the mobile client device, according to an 
5 embodiment of the present invention. 

Figures 3A, 3B, and 3C show the flow diagram of the operation of the mobile client 
device, according to an embodiment of the present invention. 

DISCUSSION OF THE PREFERRED EMBODIMENT 

10 In the following description of the preferred embodiment, reference is made to the 

accompanying drawings, which form a part hereof, and in which is shown by way of 
illustration various embodiments in which the invention may be practiced. It is to be 
understood that other embodiments may be utilized and structural and functional 
modifications may be made without departing from the scope of the present invention. 

15 The invention disclosed gives the user notice of those Bluetooth devices within 

•communication range, and yet it selectively blocks any notice about Bluetooth devices that 
the user wishes to ignore. Figure 1 A shows a wireless network diagram of six Bluetooth 
devices: the user's mobile, client device 100, four access point devices connected to their 
respective servers, and another mobile device. Access point 140 is connected to the network 

20 141. Access point 142 is connected to the printer 143. Access point 144 is connected to the 
vending machine 145. Access point 146 is connected to the second printer 147. The second 
mobile device 148 can be a Bluetooth equipped cellular telephone. In the first location of the 
mobile device 100 shown in Figure 1A, the user's mobile device 100 is within the Bluetooth 
communication range of the network access point 140, the first printer access point 142, and 

25 the vending machine access point 144. 

The four Bluetooth access point devices 140, 142, 144 and 146 and the Bluetooth 
mobile device 148 of Figure 1 A are collectively referred to here as "server devices", for 
convenience. In accordance with the invention, the server devices can indicate to the user's 
Bluetooth client device the type of service that the server device has available by sending 
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service/device icon information to Bluetooth client device. This information can be a value 
in the class-of-device (CoD) field of a frequency hop synchronization (FHS) packet that it 
sends during the process of exchanging inquiry and paging packets with the Bluetooth client 
device. If the server device has begun by transmitting an inquiry packet, then the CoD value 
5 will be sent in its paging packet. If the server device is responding to an inquiry, then its 
CoD value will be in its inquiry response packet. The network access point 140 sends the 
FHS packet 150 to the user's mobile device 100, with a CoD value of "W" indicating by 
convention that the access point 140 is connected to a network 141. The first printer access 
point 142 sends the FHS packet 152 to the user's mobile device 100, with a CoD value of 

10 "X" indicating by convention that the access point 142 is connected to a printer 143. The 

vending machine access point 144 sends the FHS packet 154 to the user's mobile device 100, 
with a CoD value of "Y" indicating by convention that the access point 144 is connected to a 
vending machine 145. 

The user's Bluetooth mobile device 100 of Figure 1 A includes an antenna 103, 

15 keypad 104, mouse or pointer device 106, and a display screen 102. The display screen 102 
presents calendar functions, mail functions, and other user applications to the user. In 
accordance with the invention, when the user's device 100 receives the FHS packet 150 with 
a CoD value = "W", a corresponding network icon 160 is displayed on the screen 102. When 
the user's device 100 receives the FHS packet 152 with a CoD value = "X", a corresponding 

20 printer icon 162 is displayed on the screen 102. When the user's device 100 receives the 
FHS packet 154 with a CoD value = "Y", a corresponding vending icon 164 is displayed on 
the screen 102. Signal strength indicators 170 can also be displayed on the screen 102 next to 
the icons 160, 162, and 164, indicating the relative signal strength of the respective FHS 
packets 150, 152, and 154. 

25 The service/device icons 160, 162, and 164 in Figure 1 A are each a small, graphic 

bitmap that is displayed on the screen 102 of the client device 100, having an appearance that 
serves to describe the service that the respective server device 141, 143, and 145 has to offer. 
Alternately, an icon can also serve to identify characteristics of the user of the server device, 
such as business-related or personal characteristics. In either case, the icon bitmap 160, 162, 
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or 164 must reside in the client device 100 in order to be displayed on its screen 102. For 
conventional services, such as an access point 140 for an Internet gateway or an access point 
142 for a printer 143, standard icon bitmaps can be stored in an icon cache 244 in all 
Bluetooth client devices 100, as shown in Figure 2. 
5 Figure 2 illustrates the memory and components of the user's mobile wireless device 

100, according to an embodiment of the present invention. The user's device can be a 
Bluetooth equipped cellular telephone, for example. The memory 202 is connected by the 
bus 204 to the Bluetooth radio 206, the keypad 104, the central processor 210, the display 
screen 102, and the cellular telephone radio 208. The memory 202 stores programs that are 

10 sequences of executable instructions which, when executed in the central processor 210, carry 
out the methods of the invention. The memory 202 includes the Bluetooth transport group 
214 that includes the link controller 216, the link manager 218, and the logical link control 
and adaptation layer 220. 

The memory 202 of Figure 2 also includes the host controller interface (HCI) 217. In 

15 systems where the higher layers are run on a host device's processor and the lower layers on a 
Bluetooth device, the host controller interface (HCI) 217 provides a standard interface 
between the higher and lower layers. The host controller interface (HCI) 217 provides event 
packets used by the lower Bluetooth layers 216, 218, and 220 to inform the higher layers of 
the host's application group 235 of changes in the lower layers. In accordance with one 

20 aspect of the invention, a received CoD register 219 is included in the memory 202, which is 
associated with the host controller interface (HCI) 217. In the current Bluetooth specification, 
the receipt of an FHS packet is reported as a result over the Host Computer Interface (HCI) 
only after the inquiry period is over, which is 10.24 seconds. During that period, it may be 
possible that the client device will move out of the range of the server device. In accordance 

25 with the invention, the receipt of an FHS packet is reported as a result event over the host 
controller interface (HCI) 217 as soon as new FHS packet arrives. The host controller 
interface (HCI) 217 is programmed to write the received CoD value of the FHS packet in the 
received CoD register 219 at the time that the FHS packet arrives. The higher layers of the 
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host's application group 235 can then immediately read the register 219 and process the CoD 
value to display the corresponding icon, as described above. 

The memory 202 of Figure 2 also includes the GSM protocol group 215 to provide 
telephony functions for the cellular telephone circuits. The memory 202 also includes the 
5 Bluetooth middleware protocol group 224 that includes the RFCOMM, PPP, IP, UDP, and 
SDP program modules. 

The memory 202 of Figure 2 also includes the application group 235. The application 
group 235 includes application programs 225 and various memory partitions. The application 
programs 225 can include GUI applications, wireless application protocol (WAP) programs, 

10 and various user applications such as calendar and email programs. The application programs 
225 also include programs to carry out the operations of an embodiment of the present 
invention, as represented by the flow diagrams of Figures 3A, 3B, and 3C. 

The application group 235 includes a screen buffer 240 showing the relative display 
positions of the icon bitmaps 160, 162, and 164 on the display screen 102. The network icon 

15 160 has the coordinates Xl.Yl. The printer icon 160 has the coordinates X2.Y2. The vending 
icon 164 has the coordinates X3,Y3. The application group 235 includes a cursor coordinate 
buffer 242 with the current values of the cursor coordinates Xc.Yc on the display screen 102. 
The application group 235 includes a response table buffer 246 listing the sending device 
address BD_ADDR of each FHS packet received. 

20 The application group 235 includes an icon cache 244 storing the icon bitmaps 160, 

162, and 164. These bit maps may have been optionally installed by the manufacturer, they 
may be optionally downloaded from a network service provider such as Nokia Club, or they 
may be optionally received from server devices such as 140, 142, etc. Icon bitmaps can be 
stored in the icon cache 244 of the client device 100 in association with their CoD values. 

25 New icon bit maps can be, for example, a new graphical design of an icon for an existing, 

assigned CoD value, such as that for a printer. The service/device icon is typically a 16 by 16 
pel bitmap. A black and white icon can be stored in a 32-byte memory partition of the 
receiver's icon cache 244. An eight bit per pel color icon can be stored in a 256-byte memory 
partition of the receiver's icon cache 244. Audible tones can be played when the icon is 
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initially displayed. The tone string can be downloaded from the Internet service provider at 
the same time as is the icon bitmap and stored in the icon cache 244 of the client device 100 
in association with the CoD value. 

The application group 235 includes a blocking filter table buffer 248 listing those 
5 CoD values that the user has selected to be ignored. The application group 235 includes a 
search table buffer 250 listing those CoD values that the user has selected to be searched. 

The application group 235 includes a detected icon buffer 252, which is shown in 
greater detail in Tables A, B, and C. Tables A, B, and C show the contents of the detected 
icon buffer 252 for the user's device 100 located at the three respective locations in Figures 
10 1A, IB, and 1C. Tables A, B, and C have the following fields: 

[1] the name of the icon's server device (network, printer, vending, etc.); 

[2] the (X,Y) coordinates of the displayed location of the icon; 

[3] the CoD value for the icon's server; 

[4] the BD_ADDR of the icon's server; 
15 [5] the time stamp for the icon; 

[6] the server rank for the icon (e.g., 1 = first printer, 2 = second printer); 

[7] the binary yes/no if there is a filter block for the icon; 

[8] the address of any associated server push (OPP) file stored for the icon; and 

[9] the RSSI strength of the FHS packet for the icon's server device. 
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Table A - Detected Icon Buffer 252 (First Location shown in Figure 1 A) 





Screen 
Location 


CoD 
Value 


BD_ADDR 
Address 


Time 
Stamp 


Server 
Rank 


Filter 
Block 


Associate 
File 


RSSI 
Strength 


Network AP 
140 


Xl.Yl 


W 


BD_ADDR1 


Tl 


1 


No 


Address 1 


RSSI1 


Printer AP 
142 


X2.Y2 


X 


BD_ADDR2 


T2 


1 


No 


Address2 


RSSI2 


Vending AP 
144 


X3,Y3 


Y 


BD_ADDR3 


T3 


1 


No 


Address3 


RSSI3 



Table B - Detected Icon Buffer 252 (Second Location shown in Figure IB) 



Name 


Screen 
Location 


CoD 
Value 


BD_ADDR 
Address 


Time 
Stamp 


Server 
Rank 


Filter 
Block 


Associate 
File 


RSSI 
Strength 


Printer AP 
142 


X2.Y2 


X 


BD_ADDR2 


T2 


1 


No 


Address2 


RSSI2 


Vending AP 
144 


X3,Y3 


Y 


BD_ADDR3 


T3 


1 


No 


Address3 


RSSI3 


Printer AP 
146 


X2.Y2 


X 


BD_ADDR5 


T4 


2 


No 


Address4 


RSSI4 



Table C - Detected Icon Buffer 252 (Third Location shown in Figure 1C) 



Name 


Screen 
Location 


CoD 
Value 


BD_ADDR 
Address 


Time 
Stamp 


Server 
Rank 


Filter 
Block 


Associate 
File 


RSSI 
Strength 


Vending AP 
144 


X3,Y3 


Y 


BD_ADDR3 


T3 


1 


No 


Address3 


RSS13 


Printer AP 
146 


X2,Y2 


X 


BD_ADDR5 


T4 


1 


No 


Address4 


RSSI4 


Mobile Device 
148 


Xl.Yl 


z 


BD_ADDR5 


T5 


1 


No 


Address5 


RSSI5 



When the icon 160, for example, is initially displayed on the screen 102 of the client 
device 100, a partition is opened in a detected icon buffer 252 shown in Table A, to store the 
status of the icon. Table A illustrates the detected icon buffer 252 for the first location of the 
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user's mobile device 100 shown in Figure 1A. A time stamp value is recorded at the start of 
the display, in association with the received CoD value. Periodically, the time stamp value is 
compared with the time of day clock of the client device. When the time stamp is older than 
a threshold value called the lease-time (30 seconds, for example), the icon is removed from 
5 the screen 102 of the device 100 and its partition is closed in the detected icon buffer 252. 
During the period that the icon remains actively displayed on the screen 102 of the device 
100, if additional FHS packets 150 are received from the same server access point device 140 
containing the same CoD value, the time stamp value is updated in the buffer 252 to the 
current time of day value. This enables retaining the display of an icon for a server device 

10 140 that remains in the vicinity of the client device 100. As soon as the client device 100 
moves out of Bluetooth communications range of the server device 140 and no more FHS 
packets 150 are received, then after the expiration of the lease-time, the icon 160 is removed 
from the screen 102 of the user's device 100. Optionally, if the icon is annoying, the user can 
manually remove the icon from the display at an earlier time, if desired. 

15 If the client device 100 has initiated a connection with the server device 140, for 

example, to carry out SDP searching or other operations, the client device 100 assumes a 
temporary master role in its new piconet. Most server devices 140, for example, are 
programmed to request a master/slave role switch if the client device 100 has initiated the 
connection. Once the client 100 changes to a slave role, it can only remain in its piconet, 

20 either as an active slave or a parked slave. (It is possible for the slave to switch between 
several piconets, when timing information is known.) Thus, the client device 100 is 
programmed to terminate such connections after completing any necessary SDP searching or 
other operations. In order to continue displaying icons of server devices 140, for example, 
within communications range, the client device 100 continues to operate in the inquiry and 

25 page scanning modes, detecting the FHS paging packets 150 and FHS inquiry response 

packets 150 from server devices 140, for example, in its vicinity. When the FHS packets 150 
from a given server device 140, for example, are no longer received, then the lease-time 
interval is started in preparation to remove the corresponding icon 160 from the display 
screen 102 of the device 100. 
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Figure IB shows the same wireless network as Figure 1A, but with the mobile client 
device having moved out of the range of the network access point and into range with a 
second printer access point. Table B illustrates the detected icon buffer 252 for the second 
location of the user's mobile device 100 shown in Figure IB. Table B shows that the server 
5 partition for the network access point 140 is removed from the detected icon buffer 252 since 
the user's device 100 has moved out of range of the access point 140 and no longer receives 
FHS packets 150. Correspondingly, the screen 102 of the user's device 100 in Figure IB 
shows that the icon 160 has been removed. Table B also shows that a new server partition 
for the second printer access point 146 is added to the detected icon buffer 252 since the 
10 user's device 100 has moved into range of the access point 146 and is now receiving FHS 
packets 156. 

The detected icon buffer 252 also stores the Bluetooth device address BD_ADDR of 
the server device 140, for example, in association with the received CoD value "W". The ith 
icon in the detected icon buffer 252 has a device address BD_ADDRi and a CoD value CoDi. 

15 The detected icon buffer 252 also stores the (x,y) coordinates of the displayed position of the 
icon with respect to the origin of coordinates on the screen 102, in association with the 
received CoD value. The ith icon on the screen 102 has a position (xi.yi) associated in the 
detected icon buffer 252 with the its CoD value CoDi. A cursor is also displayed on the 
screen 102, whose position is represented by (Xc,Yc) coordinates with respect to the origin of 

20 coordinates on the screen 102. A pointing device, such as a mouse or a track ball 106 
controls the displayed position (Xc,Yc) of the cursor on the screen 102. When the user 
presses the mouse button, the (Xc.Yc) coordinates of the cursor are compared with the (x,y) 
coordinates of each icon in the detected icon buffer 252. If the cursor coordinates (Xc.Yc) 
are within range of the ith icon coordinates (xi.yi), then the ith icon is selected. The client 

25 device 100 can be programmed to access the device address BD_ADDRi to complete the 
connection with the corresponding server device 140, for example, and exchange further 
messages with it. The further messages can include the client device 100 sending an SDP 
request to the server device 140, for example, to find out information about other files or 
services, followed by accessing a file from the server device 140. 
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Where the server device 140, for example, has initiated the connection by sending 
inquiry and paging packets 150 to the client device 100, the server device 140 may use the 
Bluetooth object push profile (OPP) to push an unsolicited file, such as a business card, to the 
client device 100. The client device 100 is programmed to store the unsolicited file in a 
5 unsolicited file buffer in the memory 202 of Figure 2, associated with the CoD and the 
BD_ADDR of the sending server device 140, for example,. The detected icon buffer 252 
opens a partition for the server device 140 and stores an indication that there is an associated 
file in the unsolicited file buffer. When the user presses the mouse button 106, the (X,Y) 
coordinates of the cursor are compared with the (x,y) coordinates of each icon in the detected 
10 icon buffer 252. If the cursor coordinates (X,Y) are within range of the ith icon coordinates 
(xi,yi), then the ith icon is selected. The client device 100 can be programmed to check if 
there is an associated file in the unsolicited file buffer. If there is, that file is accessed and 
displayed on the screen 102 of device 100. This feature enables the server device 140, for 
example, to send more informative messages to the client device 100, along with the CoD of 
15 the icon bitmap 160. 

The detected icon buffer 252 also stores a server rank value, in association with the 
received CoD value. The first server device such as the printer access point 142 having a 
given CoD type to be entered into the detected icon buffer 252, will be assigned the a server 
rank value of "1". Two different server devices, such as printer access points 142 and 146, 
20 having different device addresses BD_ADDR, can offer the same printer service and will 
transmit the same CoD value. The client device 100 is programmed to identify this 
circumstance. The second sewer device 146 of the same CoD type to be entered into the 
detected icon buffer 252 will be assigned a server rank value of "2", and so on. Instead of 
placing two identical icon bitmaps on the screen 102 of the user's device 100, the first 
25 displayed icon 162 will have appended to it a numeral indicating how many of that type of 
server device are in the vicinity. The displayed icon 162 in Figure IB is referred to as a 
multi-icon and has the numeral "2" appended to it. 

The detected icon buffer 252 also stores a received signal strength indication (RSSI) 
for each respective server device 140, 142, 144, etc. listed in the detected icon buffer 252. 
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Where there are two or more server devices 142 and 146 in the detected icon buffer 252, 
having a given CoD type, the client device 100 is programmed to rank them by their RSSI 
values. The server rank values of those servers 142 and 146 having the same type CoD value 
are reassigned, in accordance with the RSSI for each server device. The server device 142 
5 with the strongest RSSI will be reassigned a server rank value of "1", and weaker server 
devices 146 will be assigned consecutively greater values. When the cursor coordinates 
(X,Y) are within range of the multi-icon's coordinates (xi.yi), then the multi-icon is selected. 
The client device 100 can be programmed to access the device address BD_ADDRi of the 
server device 142 with the strongest RSSI to complete the connection with the corresponding 

10 server device 142 and exchange further messages with it. As individual server devices move 
out of communication range of the client device 100, the respective partition in the detected 
icon buffer 252 is cleared, and the server rank values are reassigned, as needed. 

The RSSI value can be displayed as a signal strength indicator 170 beneath each icon 
160, 162, and 164 shown on the screen 102 in Figure 1 A, thereby allowing the user to select 

15 server devices having better link quality. Alternately, "color bars" can be presented to 

represent RSSI values , such as green = good RSSI, yellow = still acceptable, and red = data 
transmission is not possible. 

The user can enter CoD values for types of server devices to be ignored, such as 
advertisement broadcasting server devices and certain types of vending machine server 

20 devices. These prohibited CoD values are stored in a blocking filter buffer 248 in the client 
device 100 of Figure 2. When a CoD value is received in an FHS packet, it is compared with 
the prohibited CoD values in the blocking filter buffer 248 and if there is a match, no entry is 
made in the detected icon buffer 252, thereby ignoring the prohibited server devices. 
There are up to eleven bits available in the CoD field for assignment as service 

25 descriptions, yielding up to 2048 different possible services that can be represented. Some 
subset, for example the six bits of the CoD minor device class sub-field, can be used to assign 
up to 64 service description values. 

When the icon serves to identify characteristics of the user of the server device, such 
as business-related or personal characteristics, the user of the sending device has the ability to 
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select the icon to be sent. The server device can be manually reset by its user to indicate in its 
class-of-device (CoD) field of its FHS packet, that particular types of service/device icon 
information are available, such as a CoD value of "Z" representing "dating/match-making" 
information. Figure 1C shows the same wireless network as Figures 1A and IB, but with the 
5 mobile client device 100 having further moved out of the range of both the network access 
point 140 and the first printer access point 142, and into range with a second mobile device 
148. The second mobile device 148 can be a Bluetooth equipped cellular telephone that has 
been selectively programmed by its user to transmit a CoD value of "Z" in its FHS packets 
158 indicating a "dating/match-making" status for its user. In this example, the icon 168 

10 shown in Figure 1C, is a standard icon that is stored in the icon cache 244 of the client device 
100 of Figure 2. Table C illustrates the detected icon buffer 252 for the third location of the 
user's mobile device 100 shown in Figure 1C. Table C shows that the server partition for the 
printer access point 142 is removed from the detected icon buffer 252 since the user's device 
100 has moved out of range of the access point 142 and no longer receives FHS packets 152. 

15 Correspondingly, the screen 102 of the user's device 100 in Figure 1C shows that the icon 
162 no longer indicates that there are two printers being detected. Table C also shows that a 
new server partition for the mobile device 148 is added to the detected icon buffer 252, since 
the user's device 100 has moved into range of the mobile device 148 and is now receiving 
FHS packets 158. 

20 The client device 100 can also be programmed to search for specified class-of-device 

(CoD) values received from a sending device 148, for example. The client device 100 can 
match the CoD values received in FHS packets 158, with an entry in a search list in the 
search table buffer 250 of the client device 100. For example, the client device 100 can be 
programmed by its user to search for that particular class-of-device (CoD) value "Z" for 

25 "dating/match-making" among those CoDs received in FHS packets. When a match is found, 
the client device 100 is programmed to display the icon bitmap 168 and sound an alarm tone. 

In an alternate embodiment of the invention, the service/device icon information can 
be sent after a connection has been made with the client device 100, as part of a Service 
Discovery Protocol (SDP) response packet. The client device 100 can search for interesting 
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services using the Service Discovery Protocol (SDP). When interesting services are found, 
their service records are accessed by the client device 100. Icons can be included in the 
service records as an IconURL parameter. Icons can be loaded using the hypertext transfer 
protocol (http). If there is no icon included in the service record of an interesting service, a 
5 default icon for its type may be displayed, as identified by the CoD value of the sending 
device 140, for example. 

The process of retrieving the icon bitmap in the Service Discovery Protocol (SDP) of 
the alternate embodiment, starts by examining the public browse root of the SDP service 
registry in the server device 140, for example. It then follows the hierarchy out to service 

10 classes which are the branches of the tree, and from there to the leaf nodes, where individual 
services are described in service records. To get specific information about the icon bitmap, 
the client device 100 and the server device 140, for example, exchange messages carried in 
SDP packets. There are two types of SDP packets, the SDP Service Search Attribute Request 
packet and the SDP Service Search Attribute Response packet. The SDP Request packet 

15 carries the SDP Service Search Attribute Request, which includes a service search pattern 
and an attribute ID list. The service search pattern is the description of the desired service 
records containing the icon bitmap information in the server device. The server device 
specifically searches its registry of for the attribute containing information about the icon 
bitmap. The server device responds with the service handle of the icon bitmap or a pointer to 

20 the icon bitmap. The service handle identifies the service record containing the icon bitmap. 
Optionally, the service record contains a pointer to the icon bitmap. When the client device 
100 receives the icon bitmap, it is displayed on the screen 102. Optionally, it can also be 
stored in the client's icon cache 244. 

The application programs 225 of Figure 2 include programs in the user's device 100 to 

25 carry out the operations of an embodiment of the present invention, as represented by the 

flow diagrams of Figures 3A, 3B, and 3C. The entry point "A" of the program of Figure 3 A 
starts with step 302, to check the receive buffer in the user's device 100 for any FHS packets, 
such as packet 150 from the network access point 140 of Figure 1 A. The receipt of an FHS 
packet is reported as a result event over the host controller interface (HCI) 217 as soon as 
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new FHS packet arrives. The host controller interface (HCI) 217 is programmed to write the 
received CoD value of the FHS packet in the received CoD register 219 at the time that the 
FHS packet arrives. The higher layers of the host's application group 235 can then 
immediately read the register 219 and process the CoD value to display the corresponding 
5 icon. Step 304 determines if an FHS packet has been received. If it has not been received, 
then the program flows to a loop including steps 306, 308, and 310 to age the timestamp 
values in the detected icon buffer 252. Step 306 checks the age of each server partition in the 
detected icon buffer 252. Step 308 determines if the difference between the time of day 
(TOD) and the timestamp is greater than the lease-time (e.g., 30 seconds) and if it is, then it 

10 removes the icon from the screen and clears the server partition in the detected icon buffer 
252. Step 310 updates all the remaining timestamps to the current time-of-day (TOD). 

If step 304 of Figure 3 A determines that an FHS packet has been received, then the 
program flows to step 312 to measure the RSSI strength and the time-of-day of the receipt of 
the FHS packet. The program then flows to step 314 to determine if the FHS packet has a 

15 new BD_ADDR sending device address. If it does not have a new device address, then the 
program flows to step 326 in Figure 3B. Step 326 updates the timestamp in detected icon 
buffer 252. Step 328 updates the RSSI in the detected icon buffer 252. Step 330 displays the 
updated RSSI indicator 170. Step 332 revises the server rank for servers with the same cod, 
based on the updated RSSI. The program then flows to the entry point "A" in Figure 3A. 

20 If step 3 14 in Figure 3 A determines that the FHS packet does not have a new 

BD_ADDR sending device address, then the program flows to step 316 in Figure 3B. Step 
316 opens a new server partition in detected icon buffer 252 and stores the BD_ADDR; CoD; 
timestamp; and RSSI for the received FHS packet. Step 318 checks the blocking filter table 
248 to determine if the CoD is has been selected by the user as prohibited and therefore to be 

25 blocked. Step 320 determines if the CoD is blocked. If it is, the program flows to step 322 to 
store the blocked indication in the detected icon buffer 252 and then to return to the entry 
point "A" in Figure 3A. No corresponding icon is displayed on the screen 102 and the 
sending server device is effectively ignored. 
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If step 320 determines that the CoD is not blocked, then the program flows to step 
324. Step 324 determines if an associated file (e.g. a push file) has been received from the 
same sending server device. If it has, then the program stores the associated file in memory 
202 and stores the associated file's address in the detected icon buffer 252. The program then 
5 flows to step 335 of Figure 3C. Step 335 determines if the CoD is the same as that for 
another server currently represented in the detected icon buffer 252. If the CoD is new and 
not the same as another in the detected icon buffer 252, then the program flows to step 336. 
Step 336 accesses an icon from the icon cache 244 corresponding to the CoD. Step 338 
displays the icon on the screen 102 at the X,Y coordinate. Step 340 stores the X,Y 

10 coordinate in the detected icon buffer 252. Step 342 displays the RSSI indicator 170 

indicating the strength of the received FHS packet. The program then returns to the entry 
point "A" in Figure 3A. 

If step 335 of Figure 3C determines that the CoD is not new, but is the same as that 
for another server currently represented in the detected icon buffer 252, then the program 

15 flows to step 344. Step 344 displays the multi-icon count near existing icon, such as the 
value "2" displayed near the printer icon 162 in Figure IB. Then step 345 determines if the 
RSSI is less than that for another server currently represented in the detected icon buffer 252. 
If the RSSI is not less, but is the greatest, then the program flows to step 346. Step 346 
assigns the highest server rank of "1" to the received FHS packet. Then step 348 revises the 

20 server ranks of the other servers having the same CoD, based on the RSSI. Step 350 stores 
the X,Y coordinate of the icon in the detected icon buffer 252. Step 352 displays the RSSI 
indicator 170 indicating the strength of the received FHS packet. The program then returns 
to the entry point "A" in Figure 3A. 

If step 345 of Figure 3C determines that the RSSI is less than that for another server 

25 currently represented in the detected icon buffer 252, then the program flows to step 354. 
Step 354 assigns a lower server rank greater than "1" to the received FHS packet. Step 356 
stores the X,Y coordinate of other icon in detected icon buffer 252, corresponding to the 
other server currently represented having the same CoD. The program then returns to the 
entry point "A" in Figure 3A. 
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The resulting invention rapidly gives the user notice of those Bluetooth devices within 
communication range, and yet does not inundate the user with information about those 
Bluetooth devices that he/she wishes to ignore. 

Although a specific embodiment of the invention has been disclosed, those having 
5 skill in the art will understand that changes can be made to that specific embodiment without 
departing from the spirit and the scope of the invention. 
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CLAIMS 

What is claimed is: 

1. A method to indicate a service available from a Bluetooth server device, 
comprising: 

receiving at a Bluetooth client device, icon information from a Bluetooth server 
device characterizing the server device; 

displaying at the client device an icon corresponding to the icon information while 
within communications range of the server device; and 

removing the display of the icon after a predetermined time interval following leaving 
the communications range of the server device. 

2. The method of claim 1, wherein said receiving step further comprises: 
receiving the icon information as a value in a class-of-device (CoD) field of a 

frequency hop synchronization (FHS) packet from the server device. 

3. The method of claim 2, wherein said receiving step further comprises: 
receiving from the server device, the CoD value in a paging packet. 

4. The method of claim 2, wherein said receiving step further comprises: 
receiving from the server device, the CoD value in an inquiry response packet. 

5. The method of claim 1 , wherein said receiving step further comprises: 
receiving the icon information as a value in a Service Discovery Protocol (SDP) 

response packet. 

6. The method of claim 1, wherein said displaying step further comprises: 
displaying a graphic bitmap on a screen of the client device, having an appearance 

that serves to describe a service that the server device has to offer. 
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7. The method of claim 1, wherein said displaying step further comprises: 
displaying a graphic bitmap on a screen of the client device, having an appearance 
that serves to identify characteristics of a user of the server device. 



9. The method of claim 8, which further comprises: 

downloading new icons from a network service provider and storing them in 
10 association with their icon information. 

10. The method of claim 9, which further comprises: 

downloading from a network service provider, representations of audible tones to be 
played when an icon is displayed, and storing the representations of audible tones in 
15 association with the icon information. 

11. The method of claim 1 , wherein said receiving step further comprises: 
receiving the icon information as a value in a class-of-device (CoD) field of a 

frequency hop synchronization (FHS) packet from the server device; 
20 reporting the CoD value over a host controller interface (HCI) when the FHS packet is 

received; and 



5 



8. The method of claim 1, which further comprises: 
storing the icon in the client device. 



processing the CoD value to display the corresponding icon. 
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12. The method of claim 1, wherein said receiving step further comprises: 
receiving the icon information using an SDP Service Search Request packet sent to 



the server device. 
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13. The method of claim 1, wherein said displaying step further comprises: 
selectively not displaying the icon based on user-defined prohibited values of the icon 
information. 

5 14. The method of claim 1, which further comprises: 

storing the icon information in a detected icon buffer. 

15. The method of claim 14, wherein said storing the icon information further 
comprises: 

storing a time stamp value at the start of the display of the icon; 
periodically comparing the time stamp value with a time of day clock of the client 
device; and 

removing the display of the icon when the time stamp is older than a threshold lease- 
time value. 

16. The method of claim 15, wherein said storing the icon information further 
comprises: 

updating the time stamp value when additional signals are received from the server 
device; and 

retaining the display of the icon for the server device as long as it remains in 
communication range of the client device. 

17. The method of claim 1, wherein said storing the icon information further 
comprises: 

25 enabling the user to selectively block the icon from display. 

18. The method of claim 14, wherein said storing the icon information further 
comprises: 

storing a Bluetooth device address BD.ADDR of the server device; 

27 
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storing (x,y) coordinates of a displayed position of the icon with respect to an origin 
of coordinates on the screen; 

representing a position of a cursor displayed on the screen by (X,Y) coordinates with 
respect to the origin of coordinates on the screen; 
5 comparing the (X,Y) coordinates of the cursor with the (x,y) coordinates of an icon; 

determining that the cursor coordinates (X,Y) are within range of an icon's 
coordinates to select the icon; and 

accessing the device address BD_ADDR corresponding to the selected icon to 
communicate with the server device. 

10 

19. The method of claim 18, which further comprises: 

sending an SDP request to the server device to determine information about 
associated files; and 

accessing the associated file from the server device. 

15 

20. The method of claim 1, which further comprises: 
receiving an unsolicited file from the server device; 
storing the unsolicited file; 

storing (x,y) coordinates of a displayed position of the icon with respect to an origin 
20 of coordinates on the screen; 

representing a position of a cursor displayed on the screen by (X,Y) coordinates with 
respect to the origin of coordinates on the screen; 

comparing the (X,Y) coordinates of the cursor with the (x,y) coordinates of an icon; 
determining that the cursor coordinates (X,Y) are within range of an icon's 
25 coordinates to select the icon; and 

accessing the unsolicited file corresponding to the selected icon to display information 
from the file on the screen. 
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21 . The method of claim 14, wherein said storing the icon information further 
comprises: 

storing a first server rank value for a first server device of a given type icon 
information; 

identifying a second server device having a different device address and said given 
type of icon information; 

storing a second server rank value for the second server device; and 

displaying a single icon on the screen representing the first and second server devices. 

22. The method of claim 21 , which further comprises: 

displaying in association with the single icon, the number of server devices detected 
having the given type icon information. 

23. The method of claim 21, which further comprises: 

displaying in association with the single icon, a received signal strength indication 
(RSSI) of one of the server devices detected having the given type icon information. 

24. The method of claim 21, which further comprises: 

displaying in association with the single icon, a received signal strength indication 
(RSSI) of one of the server devices detected having the given type icon information and 
having the strongest RSSI. 

25. The method of claim 1, which further comprises: 

storing a received signal strength indication (RSSI) for each server device detected; 
ranking the detected server devices by the respective RSSI values; and 
displaying a value representing the RSSI value for corresponding icons displayed on 
the screen. 
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26. The method of claim 1, which further comprises: 
storing prohibited icon information values; 

comparing received icon information values with the prohibited icon information 
values; and 

ignoring server devices having the prohibited icon information values. 

27. The method of claim 1, wherein said receiving step further comprises: 
receiving the icon information as a value in a minor device class sub-field of a class- 

of-device (CoD) field of a frequency hop synchronization (FHS) packet from the server 
device. 

28. The method of claim 1 , which further comprises: 
storing specified icon information values be searched; 

comparing received icon information values with the specified icon information 

values; 

displaying an icon bitmap when a match is found between a received icon information 
value and a specified icon information value. 

29. The method of claim 28, which further comprises: 
sounding an alarm tone when a match is found. 

30. The method of claim 28, which further comprises: 

sending a message to the server device when a match is found between a received 
icon information value and a specified icon information value. 

31. An apparatus to indicate a service available from a Bluetooth server device, 
comprising: 

a receiver in a Bluetooth client device, for receiving icon information from a 
Bluetooth server device characterizing the server device; 
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a display in the Bluetooth client device, for displaying an icon corresponding to the 
icon information while within communications range of the server device; and 

a processor in the Bluetooth client device, for removing the display of the icon after a 
predetermined time interval following leaving the communications range of the server 
device. 

32. The apparatus of claim 31, wherein said icon information is a value in a class- 
of-device (CoD) field of a frequency hop synchronization (FHS) packet from the server 
device. 

33. The apparatus of claim 32, wherein said icon information is a CoD value in a 
paging packet. 

34. The apparatus of claim 32, wherein said icon information is a CoD value in an 
inquiry response packet. 

35. The apparatus of claim 31, wherein said icon information is a value in a 
Service Discovery Protocol (SDP) response packet. 

36. The apparatus of claim 31, wherein said icon is a graphic bitmap having an 
appearance that serves to describe a service that the server device has to offer. 

37. The apparatus of claim 31, wherein said icon is a graphic bitmap having an 
appearance that serves to identify characteristics of a user of the server device. 

38. The apparatus of claim 31, which further comprises: 
a buffer storing the icon in the client device. 
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39. The apparatus of claim 38, which further comprises: 

said buffer storing new icons received by the receiver from a network service 
provider. 

40. The apparatus of claim 38, which further comprises: 

said buffer storing representations of audible tones to be played when an icon is 
displayed. 

41 . A computer program product to indicate a service available from a Bluetooth 
server device, comprising: 

a computer readable medium; 

program code in said computer readable medium for receiving at a Bluetooth client 
device, icon information from a Bluetooth server device characterizing the server device; 

program code in said computer readable medium for displaying at the client device an 
icon corresponding to the icon information while within communications range of the server 
device; and 

program code in said computer readable medium for removing the display of the icon 
after a predetermined time interval following leaving the communications range of the server 
device. 

42. The computer program product of claim 41 , wherein said icon information is a 
value in a class-of-device (CoD) field of a frequency hop synchronization (FHS) packet from 
the server device. 

43. The computer program product of claim 42, wherein said icon information is a 
CoD value in a paging packet. 

44. The computer program product of claim 42, wherein said icon information is a 
CoD value in an inquiry response packet. 
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45. The computer program product of claim 41, wherein said icon information is a 
value in a Service Discovery Protocol (SDP) response packet. 

46. The computer program product of claim 4 1 , wherein said icon is a graphic 
5 bitmap having an appearance that serves to describe a service that the server device has to 

offer. 

47. The computer program product of claim 41 , wherein said icon is a graphic 
bitmap having an appearance that serves to identify characteristics of a user of the server 

10 device. 

48. The computer program product of claim 4 1 , which further comprises: 
program code in said computer readable medium for storing the icon in the client 

device. 

15 

49. The computer program product of claim 48, which further comprises: 
program code in said computer readable medium for downloading new icons from a 

network service provider and storing them in association with their icon information. 

20 50. The computer program product of claim 48, which further comprises: 

program code in said computer readable medium for downloading from a network 
service provider, representations of audible tones to be played when an icon is displayed, and 
storing the representations of audible tones in association with the icon information. 
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